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(54) Four-party credit/debit payment protocol 

(57) Methods, systems, and a program, are dis- 
closed lor perfoirning electronic transactions that in- 
cludes the feature ol a Mhin" consumer's wallet by pro- 
viding issuers wilh an active role in each payment. This 
is achieved by adding an issuer gateway and moving 



the credit/debil card authorization funclion from the mer- 
chant to the issuer. This enables an issuer to independ- 
ently choose alternale authentical ion mechanisms with- 
out changing the acquirer gateway. It also results in a 
significant reduction in complexity, thereby improving 
the ease ct implementation and overall performance. 
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Description 

[0001] The invention disclosed broadly relates to computer networks and more particularly relates to electronic com- 
merce. 

5 [0002] Electronic commerce is projected to grow at a high rate and this win have a significant impact on the financial 
industry. Estimates for 1 998 are 700 million dollars worth of total revenues. Future growth promises $1 trillion by 201 D. 
No financial institution will be left unaffected by the rapid growth of electronic commerce. One obstacle thai can inhibit 
this growth, however, is the lack of secure electronic payments. Consumers and merchants are wary of transmitting 
their payment information over open networks such as the Internet and this caution affects the interest of merchants 

io and financial institutions. 

[0000] The technology of electronic commerce has adopted a number of terms that need to be defined in order to 
discuss the prior art and the invention. A short glossary of such terms follows. 

Acquirer - The financial institution (or an agent of the financial Institution) that receives from the merchant the 
1$ financial data relating to a transaction and authorizes the transaction. The acquiring institution can act as its own 

merchant certificate authority (MCA) or can contract with a third party for service. 

Authentication - In computer security, the process used to verify the Identity of a user or the user's eligibility io 
access an object; verification that a message has not been altered or corrupted; a process used to verify the user 
20 of an information system or protected resources. 

Browser • A computer program lhat allows a user to read hypertext messages such as HTML pages on the World 
Wide Web. 

2S Cardholder - A pe rson who has a valid payment card account and uses software that supports electronic commerce. 

Also known as a shopper, online shopper, consumer, or buyer. 

Certificate - A document issued by a trusted party that serves as physical evidence of the identity and privileges 
of the holder. Usually used as synonymous with an electronic certificate or digital codifies Io since an actual doc- 
30 umenl is of Utile value in a world of electronic commerce. 

Certificate authority (C A) • an organization that issues certificates. TheCA responds to the actions of a Registration 
Authority (RA) and issues new certificates, manages existing certificates, renews existing certificates, and revokes 
certificates belonging to users who are no longer authorized to use them 

55 

Certificate chain - a hierarchy of trusted digital certificates that can be 'chained" or authenticated back to the 
"chain s" ultimate trust level- the top of the hierarchy called the "root certificate.' 

Digitafrcertificate - an electronic document digitally signed by a trusted party. The digital certificate binds a person's 
40 or entity's unique name to a public/private key pair. 

Digital signature - In the context of SET Secure Electronic Transaction programs, data that is appended to, or is 
a cryptograph: transformation of, a data unit. Digital signature enables the recipient of the data unit to verify the 
source and integrity ol the unit and to recognize potential forgery. 

45 

Digital wallet or Consumer wallet • Encryption software that works like a physical wallet during electronic commerce 
transactions. A wallet can hold a user's payment information, a digital certificate to identify the user, and shipping 
information to speed transactions. The consumer benefits because his or her information is encrypted against 
piracy and because some wallets will automatically input shipping information at the merchant's site and win give 
so ihe consumer the option of paying by digital cash or cheque. Merchants benefit by receiving protection against 

fraud. The wallet is used to protect and store credit/debit information, protect the transmission of that information 
to only the people thai are authorized to see it and digitally sign purchase requests. 

Issuer - a financial institution that issues payment cards to individuals. An issuer can act as its own cardholder 
55 certificate authority (CCA) or can contract with a third party for the service. 

Key pair - In computer security, a matched set of public and private keys. When used for encryption, the sender 
uses the public key half to encrypt the message, and the recipient uses the private key half to decrypt the message. 
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When used for signing, the signer uses the private key half to encrypt a representation of the message, and the 
recipient uses the public key halt to decrypt the representation of the message for signature verification. 

Merchant server - a Web server that oflers catalogued shopping services. The equivalent to a physical store. 

5 

Password - For computer or network security, a specific siring of characters entered by a user and authenticated 
by the system in determining the user's privileges, il any, to access and manipulate the data and operations of the 
syslem. 

io Payment card - a credit card or debit card (a) that is issued by a financial institution and shows a relationship 

between the caratiotder and the financial institution and (b) for which a certificate can be issued from an authen- 
ticated certificate authority. 

Registration authority (RA) - An organization or person authorized or licensed to authenticate a certificate request- 
is er*s identity and the services that the requester is then authorized to use. The RA approves requests so that 

certificates can be issued, renewed, updated, or revoked by a CA. The RA is usually a credit officer of an issuing 
or acquiring bank and approves the certificate requests for its members. 

Secure Sockets Layer- A security protocol that allows the client to authenticate the server and all data and requests 
20 (o be encrypted. SSL offers a very limited trust model and a secure link between client and server. 

Thin wallet - generally the digital waJlel program resides on the user's PC, but a thin" wallet is placed on the card 
issuer's server, thereby reducing the program size on the user's PC and enabling an easier modification of the 
wallet's features. 

25 

Trusted Root - the base or top level certificate that provides the basis for the trusted hierarchy. 

[0004; The prior art SET Secure Electronic Transaction TM (trademark and service mark owned by SET Secure 
Electronic Transaction LLC) protocol has been developed as a method to secure bankcard transactions over public 

30 networks. SET is an open standard, multi-party protocol for conducting secure bankcard payments over the Internet. 
SET provides message integrity, authentication of all financial data, and encryption of sensitive data. 
[0005] SET is a 3-party protocol involving a cardhotding consumer, a merchant and a payment gateway operating 
on behalf of the acquiring bank, as shown in Fig. 1. When a consumer is ready to buy something from a merchant on 
the internet using a credit or debit card, the consumer's computer 102 sends a consumer payment request over internet 

35 path 1 20 to the merchant's computer 104. in a first step. The merchant's computer 1 04 forwards the consumer's payment 
request over internet path 1 22 during a second step to an acquirer gateway 106 operating on behalf of the acquirer 
bank 108. The acquirer gateway 106 passes the consumer's payment request to the acquirer bank 108 over a private 
network path 122 1 . The acquirer bank 108 sends the consumer's payment request to the card issuing bank 112 over 
the private network path 124 to check whether the consumer's credit or debit card account is active and sufficient for 

40 the proposed transaction with the merchant. The issuhg bank 112, as the card issuer, authorizes the transaction in a 
message sent over private path 1 26 to the acquiring bank 108. The acquiring bank 1 08 sends the transaction author- 
ization over private path 128* to the acquirer gateway 106, signing the message with the acquiring bank's digital sig- 
nature. The acquirer gateway 106 lorwards it over the internet path 128 to the merchant, authorizing the merchant to 
proceed with the transaction. Once ihe merchant has received the transaction authorization from the acquirer gateway 

4* 106, the merchant completes the sales transaction with rhe consumer Then later, the merchant sends a message over 
Internet path 1 42 to the acquirer gateway 1 06 to capture the transaction and get paid. The acquirer gateway then sends 
a payment message over the 1 44 to the merchant. The acquiring bank 1 08 may participate In some or all of the payment 
steps over private network paths 142' and 144*. Then, al the end of the business day, the acquiring bank will settle 
accounts with the issuing bank 11 2 over the private network. 

so [0006] It is currently not possible in the SET protocol to provide a thin - wallet feature since issuers do not have an 
active role in each payment. Nor is it possfcfe for an issuer to independently choose alternate authentication mecha- 
nisms without changing Ihe acquirer gateway. As with any system, it would also be desirable to simplify the SET protocol 
in order to enable its easier implementation and to improve its overall performance. 

[0007] Accordingly, the invention provides a method for performing electronic transactions over a computer network, 
ss comprising: sending from a merchant's computer over an internet network to a consumer's computer, a merchant 
message including a wallet initiation message, a merchant digital signature, and a digital certificate from an acquiring 
bank, said wallet initiation message including a payment amount, an order description, and a limestamp; starling a 
consumer's waUet program in said consumer's computer in response to said wallet initiation message; sending from 
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said consumer's computer consumer identity and authentication information and said merchant message, to an issuer 
gatewayfor an issuing bank; verifying at said issuer gateway sad merchants signature to prove thai the consumer is 
dealing with the actual merchant and validating at said issuer gateway the merchant's certificate and the acquirer's 
certificate to prove that the merchant and issuer share a common financial arrangement; said issuer gateway verifying 

5 the consumer's account and ensuring that funds and/or credit are available to support Ihe payment amount, then 
authorizing payment by sending over said internet network an authorization token, an issuer's digital certificate, said 
wallet initiation message, and a reference to said consumer's credit or debit card number; said authorization token 
including the payment amount, order description, tirnestamp, a random nonce plus a merchant identifier and a reference 
to the consumer's credit or debit card number: and said merchants' computer receiving said authorization token and 

10 fulfilling said order description. 

[0008] In a further aspect, the invention provides a system for performing electronic transactions over a computer 
network, comprising: a merchant's computer (or seruling over an internet network to a consumer's computer, a merchant 
message including a wallet initiation message, a merchant digital signature, and a digital certificate from an acquiring 
bank, said wallet initiation message including a payment amount, an order description, and a tirnestamp; a consumer's 

is wallet pfogram in said consumer's computer responsive to said wallet initiation message, for sending from said con- 
sumer'scomputer consumer idenlity and authentication information and said merchant message, to an issuer gateway 
lor an issuing bank; an issuer gateway for verifying said merchant's signature to prove that the consumer is dealing 
with (he actual merchant and validating at said issuer gateway the merchant's certificate and the acquirer's certificate 
to prove that the merchant and issuer share a common financial arrangement; said Issuer gateway verifying the con- 

zo sumer's account and ensuring that funds and/or credit are available to support Ihffpaymeni amount, then authorizing 
payment by sending over said internet network an authorization token, an issuer's digital certificate, said wallet initiation 
message, and a reference to said consumer's credit or debit card number, said authorization token including the pay- 
ment amount, order description, tirnestamp, a random nonce plus a merchant identifier and a reference to the con- 
sumer's creditor debit card number; and said merchant's computer receiving said authorization token and fulfilling said 

2$ order description. 

[0009] In a yet further aspect, the invention provides a data processing system for performing electronic transactions, 
comprising: a computer processor means for sending from a merchant's computer over an internet network to a con- 
sumer'scomputer, a merchant message including a wallet Initiation message, a merchant digital signature, and a digital 
certificate from an acquiring bank, said wallet initiation message including a payment amount, an order description, 

30 and a tirnestamp: means for starting a consumer's wallet program in said consumer's computer in response to said 
wallet initiation message; means for sending from said consumer's computer consumer identity and authentication 
information and said merchant message, to an issuer gaieway for an issuing bank; means for verifying at said issuer 
gateway said merchants signature to prove that the consumer is dealing with the actual merchant and validating at 
said issuer gateway the merchants certificate and the acquirer's certificate to prove that the merchant and issuer share 

35 a common financial arrangement; said issuer gateway verifying the consumer's account and ensuring that funds anoV 
or credit are available to support the payment amount, then authorizing payment by sencfing over said internet network 
an authorization token, an issuer's digital certificate, said wallet initiation message, and a relerence to said consumers 
credil or debit card number; said authorization token includhg the payment amount, order description, tirnestamp. a 
random nonce plus a merchant identifier and a reference to the consumer's credit or debit card number; and said 

4Q merchant's computer receiving said authorization token and \ ulfilBng said order description. 

[0010] In a yet still further aspect. Ihe invention provides a computer program product, comprising; computer program 
code means for sending from a merchants computer over an internet network to a consumer's computer, a merchant 
message including a wallet initiation message, a merchant digital signature, and a digital certificate from an acquiring 
bank, said wallet initiation message including a payment amount, an order description, and a tirnestamp; computer 

45 program code means for starting a consumer's wallet program in said consumer's computer in response to sad wallet 
initiation message; computer program code means for sending from said consumer's computer consumer identity and 
authentication information and said merchant message, to an issuer gateway for an Issuing bank; computer program 
code means for verifying at said issuer gateway said merchant's signature to prove that the consumer is dealing with 
the actual merchant and validating at said Issuer gateway the merchants certificate and the acquirer's certificate to 

50 prove that the merchant and issuer share a common financial arrangement; said issuer gateway verifying the consum- 
er's account and ensuring that funds and/or credil are available to support the payment amount, then authorizing 
payment by sending over said internet network an authorization token, an issuer's digital certificate, said wallet initiation 
message, and a reference to said consumer's credil or debit card number; said authorization token including the pay- 
ment amount, order description, tirnestamp, a random nonce plus a merchant identifier and a reference to the con- 

55 Burner's credil or debit card n umber; and said merchants computer receiving said authorization token and fulfilling said 
order description. 

[0011] In a yet still further aspect, the invention provides a method for performing electronic transactions over a 
computer network, comprising: sending from a consumer's computer to an issuer gateway for an issuing bank, an 
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authorization request message containing consumer identity and authentication information, payment amount, an order 
description, a timesramp, a dgital certificate representing a merchant, and a digital certificate representing the mer- 
chant's acquiring bank; said merchant's digital certificate containing a merchant Identifier unique for the acquinng bank; 
said acourring bank's digital certificate containing a bank Identifier unique among ail banks sharing a common financial 

s arrangement; validating at said issuer gateway the merchant's certificate and the acquirer's certificate to prove that 
the merchant, acquirer, and issuer share a common financial arrangement; said issuer gateway verifying the consum- 
er's account and ensuring lhat funds and/or credit are available to support the payment amount, then authorizing 
payment by sending over said internet network an authorization token, an issuer's digital certificate, and a reference 
to said consumer's credit ordebit card.number; said. authorization token including the payment amount, order descnp- 

10 lion limeslamp, a random nonce, said merchant identifier from the merchant's digital certificate, and said acquiring 
bank identifier from said acquiring bank's digital certificate, plus a reference to the consumer's credit or debit card 
number, said authorization token being digitally signed by the issuing bank; and said merchant's computer receiving 
said authorization token and fulfilling said order description. 

(001 2] According to the preferred embodiment the consumer identity and authentication inl ormalion may be a usend 
is and a password, an ATM debit card number and PIN, a smart card's account number and a symmetric Message 
Aulhentication Code (MAC), a smart card's account number and an asymmetric digital signature, a consumer's digital 
signature and digital certificate, a consumer's digital certificate and matching asymmetric digital signature, a user ac- 
count number and a symmetric MAC or asymmetric digital signature, a user account number and an asymmetric digital 
signature, or a consumer's biometrlc signal. 
20 [00 1 3] In the preferred embodiment there is a digital certificate hierarchy that covers issuing banks, acquiring banks, 
and merchants. The certificate hierarchy is used with public-key digital signatures to identity said merchant and said 
issuing Dank. The certificates represent common financial agreements and obligations among the merchant and the 
issuing bank. The issuing bank certificates identify and help authenticate issuing banks to merchants, providing a basis 
for the merchants to trust the authorization tokens provided by the issuing banks. An acquiring bank certificate and a 
25 merchant certificate idontify and help authenticate the acquiring bank and the merchant to issuing banks. The merchant 
certificate identifies the merchant to the consumer and verifies that the merchant is a valid participant of a payment 
schema, before the issuing bank provides said authorization token. 

[0014] Thus electronic transactions can be performed, in accordance with a preferred embodiment of the present 
invention using a thin' consumer's wallet by providing Issuers with an active role in each payment. This is achieved 
30 by adding an issuer gaieway and moving the credh/debit card authorization lunctton from the merchant to the issuer. 
This enables an issuer to independently choose alternate authentication mechanisms without changing the acquirer 
gateway. It also results in a significant reduction in complexity, thereby improving the ease of implementation and 
overall performance. 

(0015) According to a preferred embodiment, the method of the invention includes the step of sending from a con- 
3s S umer\s computer a start message over an internet network to a merchant's computer. The merchant's computer then 
replies to the consumer's computer with a merchant message including a wallet initiation message, a merchant digital 
signature, and a digital certificate from an acquiring bank. The wallet initiation message includes a payment amount, 
an order description, a timestamp, and a nonce. This starts a consumer's wallet program in the consumer's computer 
in response to the wallet initiation message. The consumer's computer then sends over the internet network some 
40 consumer identity and authentication information, such as a userid and user password, plus the merchant message, 
to an issuer gateway operating on behalf of an issuing bank. 

[0O16J The issuer gateway verifies the merchant's signature to prove that the consumer is dealing with the actual 
merchant and validates the merchant's certificate and the acquirer's certificate to prove that the merchant and issuer 
share a common financial arrangement. The issuer gateway then verifies that the consumer's account is active and 

45 has sutlicient funds and/or credit to support the payment amount. The issuer gateway then authorizes payment by 
sending over the internet network an authorization token, an issuer's digital certificate, the wallet knitiaiion message, 
and a reference value representing the consumer's credit or debit card number. The authorization token Includes the 
payment amount, order description, limeslamp, a random nonce plus a merchant identifier and the reference to the 
consumer's credit or debit card number. The issuer gateway signs the authorization token. This information can be 

so sent either to the consumer or to the merchant to fulfil the order description, if sent to the consumer, the consumer 
forwards the authorization token to the merchant. The merchant verifies the issuer's signature, issuer's digital certificate, 
and authorization token contents to validate that the payment is authorized by the issuer. 

[0017] Once the merchant has received the authorization token from the issuer gateway, the merchant completes 
the sales transaction with the consumer The merchant may choose whether to do the authorization in real time (while 
55 the consumer waits) or later. Then later, the merchant sends a message, including the reference value representing 
the consumer's card number, over the internet to an acquirer gateway operating on behalf of an acquirer bank, to 
capture the transaction and get paid. The acquiring bank will settle accounts with the issuing bank over a pnvate 
networx by sending a settlement message that includes the reference to the consumer's card number. The issuing 
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bank wiB convert the reference value into the consumer's card number and apply the transaction amount to the con- 
sumer's balance in his credit card or deposit account. 

[001 8] » the transaction is later disputed, the merchant can prove that the issuer authorized the payment by producing 
a copy of the authorization token. The combination of the issuer's signature on the authorization token, the issuers 
s digital certificate, and the contents of the authorization token provide undeniable proof that the issuer authorized the 
payment. 

[0019] If privacy is desired, the communication among the consumer wallet, issuer gateway, and merchant can be 
protected via the Secure Socket Layer (SSL) protocol. SET was designed for both Web and email use. The start and 
wallet initiation messages. described above would not be used in an email implementation, however, the rest is as 
io previously described. The contents of the wallet initiation message in an email implementation comes from another 
source, such as a CD-ROM, in which case, it could not ba signed. 

[0020] n this manner a thin" wallet is enabled for the consumer In an electronic commerce protocol that is signifi- 
cantly simpler than the SET protocol, thereby improving overall performance and enabling greater flaxfoility for issuer 
in the authentication of cardholders. 

is [0021] A preferred embodiment of the present invention further provides a financial institution's digital certificate 
containing a network address or URL that identities the network location of the financial institution contacted via an 
internet network as part of a payment protocol. This can be applied to both the issuing bank and the acquiring bank. 
[0022] A preferred embodiment o! the present Invention wBI now be descrtoed in detail, by way of example only, with 
reference to the following drawings: 

20 [0023] Figure 1 illustrates the prior art SET three-parly protocol. 

[0024] Figure 2A illustrates the four-party protocol, in accordance with a preferred embodiment of the present inven- 
tion. 

[0025] Figure 2B illustrates the route of the authorization token in the tour-party protocol, in accordance with a pre- 
ferred embodiment of the present invention. 
25 [0026] Figuro 2C illustrates the use of a consumer's smart card in the lour-party protocol, In accordance with a 
preferred embodiment of the present invention. 

[0027] Figure 3 is a flow diagram of the four-party protocol, in accordance with a preferred embodiment of the present 
invention. 

[0028] Figure 4 illustrates a variation in the four-party protocol, wherein the signed authorization token is sent directly 
30 to the merchant, in accordance with an aliematlve preferred embodiment of the present invention. 

[0029] Figure 5 illustrates the four-party protocol as applied to a plurality of issuing banks, in accordance with a 
preferred embodiment of the present invention. 

[0030] Figure 6 illustrates the four-party protocol as applied to a plurality of issuing banks and a plurality ol acquiring 
banks, in accordance with a prelerred embodiment of the present invention. 
35 [0031] Figure 7 illustrates the issuer gateway processor, in accordance with a preferred embodiment of the present 
invenltor. 

[0032] Figure 8 is a flow diagram of the issuer gateway process in the tour-party protocol, in accordance with a 
preferred embodiment of the present invention. 

[0033) Figure 2A Blustrates the four-party protocol, in accordance with a preferred embodiment of the present inven- 

40 iron. An issuer gateway is provided and the credit/debit card authorization function is moved from the merchant to the 
issuer. The lour-party protocol method includes the step of sending from a consumer's computer 202 a start messages 
220 over an internet network to a merchant's computer 204. The merchants computer 204 then replies to the consum- 
er's computer 202 with a merchant message including a wallet initiation message 222, a merchant digital signature, 
and a digital certificate from an acquiring bank 208. The wallet initiation message includes a payment amount, an order 

« description, a timeslamp, and a nonce. This starts a consumer's wallet program in the consumers computer 202 in 
response to the wallet initiation message. The consumer's computer 202 then sends a message 224 over the internet 
network including some consumer identity and authentication Information, such as a userld and user password, plus 
the merchant message, to an issuer gateway 21 4 operating on behalf of an issuing bank 212. 
[0034] The acquimg bank's digital certificate can contain a network address or URL that identifies the network lo- 

so cation ot the acquiring bank contacted via an internet network as part of a payment protocol. 

[0035] In the preferred embodiment the issuer gateway 214 verifies the merchant's signature to prove that the con- 
sumer is dealing with the actual merchant and validates the merchant's certificate and the acquirer's certificate to prove 
that the merchant and issuer share a common financial arrangement. The issuer gateway 214 then verifies that the 
consumer's account is active and has sufficient funds and/or credit to support the payment amount. Then, as shown 

55 (n Figure 2B, the issuer gateway 214 then authorizes payment by sending over the internet network an authorization 
token 254 over path 226, an issuer's digital certificate, the wallet initiation message, and a reference number or value 
252' representing the consumer's credit or debit card number. The reference number 252" is created by the issuing 
bank 212, for example by preparing a table or credit card or debit card numbers 250 and a corresponding table of 
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reference number 252. The issuing bank pairs the consumer's card number 250 with a selected reference number 252 
and outputs the reference number over path 226' to the issuer gateway 214. The issuer gateway then includes the 
reference number 252' with the authorization token 254. The authorization token 254 includes the payment amount, 
order description, timestamp, a random nonce plus a merchant identifier and the reference number 252* to the con- 

5 sumer's credit or debit cardnumber. The issuer gateway 21 4 signs the authorization, token 254 on behail of the issuing 
bank 212. This information can be senl either to the consumer 202 over path 226 as show in Figure 2B. or directly to 
the merchant 204 over path 402 as shown in Figure 4, to fulfil the order description. If sent to the consumer 202 in 
Figure 2B, the consumer forwards the authorization token 254 to the merchant 204 over path 228. as shown in Figure 
28. The merchant 204 verifies the issuer's signature, issuer's digital certificate, and authorization token contents to 

10 validate that the payment is authorized by the issuer 212. 

[00361 The issuing bank's digital certificate can contain a network address or URL that identifies the network location 
of the issuing bank contacted via an internet network as part of a payment protocol 

[0037] Once the merchant 204 has received the authorization token 254 from the issuer gateway 214, the merchant 
204 completes the sales transaction with the consumer 202. The merchant 204 may choose whether to do the author- 

is ization in real time (while the consumer 202 waits) or tater. Then later, the merchant 204 sends a capture request 
messages 256 over path 242, including the reference number 252' representing the consumer's card number, over the 
internal to an acquirer gateway 206 operating on behalf of an acquirer bank 208. to capture the transaction and gel 
paid. The acquiring bank 208 will settle accounts wtth the Issuing bank 21 2 over a private network shown In Figure 2B, 
by sending a settlement message 258 that includes the reference number 252 to the consumer's card number. Ttie 

20 issuing bank 212 will convert the reference number 252' into the consumer's card ntxmber 250 and apply the transaction 
amount to the consumer's balance in his credit card or deposit account. 

10033] |f the transaction is tater dfeputed, the merchant 204 can prove that the issuer 212 authorized the payment 
by producing a copy of the authorization token 254. The combination of the issuer's signature on the authorization 
token the issuer's digital certificate, and the contents of the authorization token provide undeniable proof thai the issuer 
25 authorized the payment. 

[003S] It privacy is desired, the communication among the consumer wallet, issuer gateway, and merchant can bo 
protected via the Secure Socket Layer (SSL) protocol. 

[0040J The above approach can be applied to both the internet World Wide Web and to email use. The start message 
220 and wallet mitialion messages 222 described above would not be used in an email implementation, however, the 
30 rest is as previously described. The contents of the wallet initiation message in an email implementation comes from 
another source, such as a CD-ROM, in which case, it could not be signed. 

[0041] In this manner, a 'thin* wallet is enabled for the consumer in an electronic commerce protocol that is signifi- 
cantly simpler than the SET protocol, thereby improving overall pedormance and enabling greater flexibility for issuer 
in the authentication of cardholders. 

as [0042] Figure 2C illustrates the use of a consumer's smart card in the four-party protocol, in accordance with a 
preferred embodiment of the present invention. The smart card 262 owned by the consumer can be used to authenticate 
the consumer to the issuer gateway. When the consumer's computer 202 sends an attempt message 272 which at- 
tempts to connect with the Issuer gateway 21 4, the issuer gateway responds to theconsumer computer with a challenge 
message 274 The consumer computer 202 then passes the challenge on to the smart card reader 260, which passes 

40 h on as the chaDenge 274' to the smart card 262. The smart card 262 then signs the challenge with it digital signature 
and returns the signed challenge response 276 to the consumer's computer 202. The consumer's computer 202 then 
combines the signed challenge response 276 with the merchant's initiation message 224 and sends it on to the issuer 
gateway. The issuer gateway 21 4 verifies the smart card's signature and thus verifies the consumer's identity 
[0043] It is possible to choose Irom a variety of methods to perform authentication ol the consumer wilh the issuer 

45 gateway 214. Examples include a userid and a password, an ATM debit card number and PIN, a smart card's account 
number and a symmetric Message Authentication Code (MAC), a smart card's account number and an asymmetric 
digital signature, a consumer's digital signature and digital certificate, a consumer's digital certificate and matching 
asymmetric digital signature, a user account number and a symmetric MAC or asymmetric digital signature, a user 
account number and an asymmetric digital signature, or a consumer's biometric signal. This wide choice of authenti- 

so cation methods between the consumer and the issuer gateway is possible because issuers have an active role in each 
payment. This enables an issuer to independently choose alternate authentication mechanisms without changing the 
acquirer gateway. 

[0044] Figure 3 Is a flow diagram 300 of the four-party protocol, in accordance with a prelerred embodiment of the 
present invention. It begins with step 302 where the consumer presses the 'pay* button on the merchant's HTML 
55 internet browserpage to send the start message tothe merchant. Then in step 304, the merchant sends to the consumer 
the wallet initiation message wilh the payment amount, order description, timeslamp, and nonce. Tne merchant signs 
the message and includes a digital certificate from the acquiring bank. Then in step 306, the consumer's wallet is 
Started, the consumer togs on, and the user's identification and authentication inlormation and the merchant's initiation 
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message are sent to the issuer gateway. Then in step 308, the issuer gateway verifies the merchant's signature to 
prove that the consumer Is dealing wfih the actual merchant, validates the merchant's certificate and the acquirer's 
certificate lo prove that the merchant and issuer share a common financial arrangement Assuming that the issuer is 
happy for the payment to proceed in view of the funds available to that consumer, then in step 310. the issuer gateway 
5 authorizes payment by sending over the internet network an authorization token, an issuer's digital certificate, the wallet 
initiation message, and a reference to the consumer's credit or debit card number. Then in step 312, the authorization 
token including the payment amount, order description, timestamp, a random nonce plus a merchant kJentSier and a 
relerence to the consumer's credit or debit card number are forwarded to the merchant. Then later in step 314, the 
merchant submits the authorization token in a capture request to the acquirer bank. Then in step 316, the acquirer 
to bank settles with the issuer bank. 

[0045] Figure 4 illustrates a variation in the four-party protocol, wherein the signed authorization token is sent diroctfy 
to the merchanl on path 402 and the merchant sends a confirmation message 410 to the consumer 
[0046] Figure 5 illustrates the four-party protocol as applied to a plurality oi issuing banks, in accordance with a 
preferred embodiment of the present Invention. Here a plurality of issuing banks 212A, 212B, and 212C can commu- 
'5 nicale ove' private networks with a common issuer gateway 214. 

[0O47J Ftgure 6 illustrates the lour-party protocol as applied lo a plurality of issuing banks and a plurality of acquiring 
ban ks. Here a plurality of issuing banks 21 2A, 2 1 2B, and 21 2C can communicate over private networks with a common 
issuer gateway 214 and a plurality ol acquiring banks 208A, 208B, and 208C can communicate over private networks 
with a common acquirer gateway 206. 
20 [0048] Figure 7 illustrates the issuer gateway processor, in accordance with a preferred embodiment ol the present 
invention. The processor 700 includes a memory 702. a bus 704, a CPU processor 708. and an Issuer gateway trans- 
action manager base switch 770. The base switch 770 includes a front-end that includes a front-end local server 774, 
a Ironl-end HTTP server 776, and a front -end TCP server 778. The base switch 770 includes a back-end that includes 
a back-end UNIX client 780, a back-end TCP/IP client 782, and a back-end LU6.2 client 784. A router 772 connects 
25 the f ronl-ond to tho back-end. The front-end is connected to consumers 202 and the back-end is connected lo issuers 
212. The memory 702 includes issuer "A" interface buffers 730, issuer P B" interface buffers 740, the lour-party credit/ 
debit payment protocol program 750, front-end server communication protocols 752, back-end client communication 
protocols 754, and the operating system 756. The programs stored in the memory 702 are sequences of executable 
instructs which when executed in the CPU 708 perform the methods described above, 
30 [0049] Figure B is a flow diagram 800 of the issuer gateway process in the tour-party protocol, in accordance with a 
preferred embodiment of the present invention. In step 802. the issuer gateway receives the consumer's credit request. 
Then step 804 authenticates the message using the consumer's userid and authentication information. Then step 806 
authenlcates the merchant's wallet initiation message using the merchant's public key and digital certificate. Then step 
808 confirms that the consumer's credit or deposit is sufficient for the transaction. Then step 810 accesses from the 
35 issuer a consumer reference number corresponding to the consumer's credit card number. Then step 812 generates 
an authorization token signed with the issuer's signature using a private key and digital certificate. Then step 814 sends 
to the consumer's wallet the signed authorization token and the issuer's certificate, with the wallet initiation message 
and the consumer's card reference number. Then step 816 sends a confirmation to the Issuer. 
[0050] "ne approach described above has many advantages. It fits well with server-based (thin) wallets (which op- 
40 erate in the issuer gateways). It separates the authentication technology used between the consumer and issuing bank 
from the remainder of the payment protocol. It permits each issuing bank lo determine how it will authenticate its 
consumers (e.9. userid/password, symmetric or asymmetric keys with or without digital certificates or smart cards, or 
other security hardware.) It avoids the use of digital certificates for consumers. It eliminates the cosl and delay of real- 
time authorization through the private network between the acquirer and the issuer. II reduces overhead lor merchant 
45 and payment gateway, since payments are authorized before they reach the merchant, and since much less cryptog- 
raphy is required. It provides protection for the credit or debit card number, without using encryption. It complies with 
U.S. export laws and foreign cryplography usage laws by not using any encryption. It has potential for lower develop- 
ment and testing costs (compared to SET) because of a simpler design. Examples ol the simpler design include avoid- 
ance of encryption; elimination of the requirement for consumer certificates; and avoiding any requirement for the 
so consumer wallet lo validate certificates, generate digital signatures, or verify digital signatures. The invention supports 
Japanese Payment Options and other issuer-based payment features in a manner simpler than SET. 
[0051] * more detailed discussion of the protocol steps lollows: 

1 In Figure 2A. path 220, the consumer uses a browser lo shop at a merchanl WWW site. The consumer presses 
ss a 'pay' button on the merchant's HTML page, or otherwise indicates that the consumer is ready lo make a payment. 

In Figure 2A. path 222. the Merchant sends a wallet initiation message to the consumer, conlainmg payment 
amount, order description, timestamp, a random nonce, and possible additional data depending upon require- 
ment The merchant signs this initiation message and includes a digital certificate provided by the acquirtng bank 
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2 In Figure 2A path 224. the Wallet initiation message causes the consumer's browser to start the consumer's 
wallet The consumer is prompted to logon to the wall* using userid/password. smartcard, or other appropriate 
authentication mechanism. The wallet sends data from step 1, plus the consumer's identity and authentication 
data to the issuer gateway. 

* 3 in Figure 2A palh 226, the Issuer galeway verifies Ihe merchant's signature and digital certificate lo validate 

that the merchant and issuer share a common financial arrangement established by national law or financial as- 
sociation such as MasterCard. Visa, an ATM network, or similar organization. The issuer gateway authorizes pay- 
ment via the issuer's credit card processing system. The issuer gateway generates and sends a signed authori- 

io zation token to the consumer wallet, along with the Issuer gateway's certificate. The authorization token conlains 
the data from step 1 plus a merchant identifier and a reference to the consumer's credit card number. The refer- 
ence' is discussed below in more detail. 

Note lhat Ihe authorization token is "bound" to the particular payment by the reference to the consumer's credrt 
card number, merchant identifier, payment amount, timestamp, and nonce. This means that a specific authorization 

is token is good lor just one payment 

4 in Figure 2A. path 228. the consumer's wallet lorwards the authorization token to the merchant, which can verily 
both the issuer gateway's signature and the data In the authorization token. No separate realtime authorization Is 
required since the payment is 'pre-authorlzed* before it reaches the merchant. 



5 In Figure 2A path 242. at some later time, the merchant submits the authorization token in a capture request 
to the acquirer's payment gateway. The capture requests tells the acquirer lo actually post Ihe charge to the con- 
sumer's credrt or debit account. Confidentiality of these messages can be obtained. If desired, by t ransmrtting them 
within SSL sessions. The integrity and authenticity ol the messages does not depend upon SSL so that the mes- 
as sages can be used both to authorize ongoing processing steps, and to provide proof lhat the transactions occurred. 

[00521 Note that the consumer wallet software necessarily provides very little function in this design. Most of Ihe 
payment protocol function is performed in the issuer gateway. At minimum, the wallet provides some method ol au- 
thenticating the consumer to the issuer gateway, as discussed below. If consumer wallets are stored among issuers. 
30 then tne authentication scheme must be shared, but the authentication data (e.g. smart card) could be dtflerent for 
each issuer. If consumer wallets are nol shared among multiple issuers, as shown in Figure 5. then the authentication 
mechanism (smartcard, userid/password) could be different for each issuer. 

100531 The consumer wallet must provide payment request timeout and retry functions Most other functons can be 
placed in either the consumer wallet for the issuer gateway. These include most of the user interlace, the payment 

35 inquiry function, the payment transaction log. support for multiple consumer cards, and support for payment selection. 
Implementing these functions al the consumer machine would result in a far wallet; implementing them in the issuer 

gateway would resull in a "thin" wallet , . M 

[00541 Message processing f unctions (parsingandchecking incoming messages, generating comp lex outgotrig mes- 
sages) are much simpler than In SET. since no encryption is used; the wallet need not examine the merchant s data 

40 in steo 1 and the authorization token from step 2; and the wallet neither generates nor verifies •to""""*- 

[00SS1 The merchant, acquirer gateway, and issuer gateway should implement replay delection both lo handle error 
retries and to defend against malicious replay attacks. 

Relerence lo Credit/Debit Card Number 

[0056] At protocol siep 3, the issuer gateway includes a 'reference- to the consumers card number in the authorization 
token If the actual card number were used, the authorization loksn-or at least the card number-would have to be 
encrypted in protocol steps 3, 4. and 5. Instead, the 4-party protocol uses a 'relerence', which can be composed m 
either of the following ways: 

a The reference is an 'alias card number*, meaning a secondary account number that is mapped at ihe issuing 
bank lo the real card number. This is similar to an approach discussed (and rejected) during Ihe SET design, and 
actually used in the X9.59 ANSI draft. The alias card number is only used for Internet-based transactions that are 
accompanied by an authorization token. A stolen alias card number has no use without an authorization token, so 
ss ri does not entaS any risk to real-world cred* cards. 

fc. The relerence is an authorization number allocated uniquely by the issuer galeway for each authorization. This 
authorization number is passed by the acquirer galeway back to the issuing bank in Ihe caplure message, me 
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issuing bank maintains a database mapping authorization numbers to card numbers. When the issuing bank re- 
ceives the capture message, it uses this database mapping to determine the actual card number. 

{0057] To support this design, the authorization token would include a dummy card number for use in routing the 
S payment to the appropriate issuer. This dummy card number could be shared among all cardholders using this 4-party 
protocol. Either ot these alternatives can support interlacing to the existing capture networks that interconnect acquiring 
and issuing banks. 



20 



Certificate.Hierarchy 

[0058] The 4-party protocol is supported by a certificate hierarchy that covers issuing banks, acquiring banks, and 
merchants. The certificate hierarchy is used with standard asymmetric (public-key) digital signatures to identify Ihe 
protocol participants to each other. The certificates represent the common financial agreements and obligations among 
these parties. In particular, the issuing bank certificates identify and help authenticate issuing banks to merchants, 
providing a basis for the merchants to trust the authorization tokens provided by the issuing banks. The acquiring bank 
and merchant certificates identity and help authenticate the corresponding participants to issuing banks. This serves 
several purposes: (a) idenlities the merchant to the consumer; (b) verifies that the merchant is a valid participant of 
the payment scheme before the Issuing banks provides an authentication token; (c) helps deter some forms ot attack 
on issuing banks by requiring participation of both a consumer and merchant in an attack. The certificate hierarchy is 
illustrated in the following Table: 



TABLE I 





Certificate Type 


Purpose 


Issuing Party 


Relying Parties 


25 


Rool 


Provide trust base for entire protocol 


Rool (set\) 


All 




Issuing bank 


Identify & help authenticate valid issuing banks 
to merchants 


Root 


Merchant, Acquiring bank 


30 


Acquiring bank 


Identity & help authenticate valid acquirers to 
issuing banks and consumers. 


Root 


Issuing bank, consumer 


35 


Merchant 


Identity & help authenticate valid merchants to 
issuing banks and consumers. 


Acquiring Bank 


Issuing bank, consumer 



40 



45 



50 



55 



[0059] Consumer certificates are not required, since the consumer authenticates to the consumer's own Issuing 
bank. The consumer and bank have a long-term established relationship, so the bank can keep the symmetric or 
asymmetric key required to authenticate the consumer. 

[0060] X.509 or other established digital certificate formats are used. Each certificate identifies the certificate owner 
by name, physical address, network address, and so forth. In particular, the issuing gateway's certificate should contain 
the issuing gateway's network address to support split, recurring, and instalment payments as described below. The 
merchant's certificate should contain the merchant's name, address, and contact information to assist dispute resolu- 
tion. The merchant's certificate should identify the acquiring bank that hold the merchant's business account used to 
settle payments. 

[0061] The certificate hierarchy is rooted by an authority jointly trusted by the banks. The root could be run by indi- 
vidual BrerJI or debit brand associations, such as MasterCard, Visa, or the ATM network associations; by a national 
regulator such as the Federal Reserve; or by an international organization such as the WTO or World Bank. The choice 
ot who runs the root is associated with the question of who establishes and enforces the business and regulatory 
arrangements between the issuing and acquiring banks. If national or international commercial laws define these ar- 
rangements (as with paper checks), then a public organization would be appropriate. If private bHaleral or multi-lateral 
banking contracts define these arrangements, then financial associations (such as MasterCard or Visa) might operate 
the roc*. The organization of the certificate hierarchy should reflect the business arrangements. Possible arrangements 
could include separate hierarchies for separate countries or financial associations (e.g. one hierarchy for visa, and 
another for MasterCard); a shared hierarchy as with SET (e.g. an industry root that grants certificates to sub-trees lor 
financial associations or countries); or other variations. 
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Consumer Authentication 

[00621 An advantage of this design is the lact that the issuing bank can choose the technology used to authenticate 
the consumer to the issuer gateway. Possibilities include many standard techniques common in the industry: 

5 

Userid and password, tor example as provided by basic authentication in standard WWW browsers- 
Account number and ATM PIN. 

to Soltware- or smart card-based symmetric or asymmetric authentication, where the issuer gateway obtains match- 
ing Key verification information from a database. 

Asymmetric authentication using digital certificates, for example using SSL v3 as implemented in WWW browsers, 
"piis could be implemented using either software or smart cards. 

is 

Proprietary hardware tokens. 
Biometrics. 

20 [0063] End-user authentication involves a complex trade-off between cost, security, risks, portability and end-user 
convenience. Furthermore, the trade-offs change over time as new user authentication technology is invented. Unlike 
SET, the 4-party protocol design allows individual issuing banks to make their own choices lor their customers, inde- 
pendently of the digital certificate technology used to authenticate merchants to issuers, and banks to each other 
Split Shipments, Recurring Payments, and Instalment Payments. 

25 

SET provides the lot towing features: 

SplH shipments support merchants who must back-order merchandise. 

jo The merchant can divide a payment into two or more portions that are separately authorized and settled, without 

consumer interaction. 

Recurring payments support merchandising schemes such as monthly newspaper subscriptions. The merchant 
can authorize and capture payments on a regular schedule, given initial consumer approval and without further 
35 consumer irwotvemeni 

Instalment payments permit consumers and merchants to stretch a payment over time. At the time of a purchase 
me consumer and merchant agree to a particular schedule and the merchant or acquiring bank then automatically 
authorize and capture payments according to the schedule. 

40 

[0064] Split shipments are supported in the 4-party protocol by an additional message interaction between the mer- 
chant and issuer gateway, as shown in Figure 4. When the merchant discovers that it needs to split a shipment, it 
sends the authorization token from step 3 to the issuer gateway identified in the issuer's digital certificate. This is a 
message on path 402. The merchant includes the details of the split requirement, such as the amount of the first 

« payment. The merchant authenticates the request by signing it and inducting ihe merchant's digital certificate. The 
issuer gateway can verify that the merchant signing message is Ihe same merchant that signed the original request 
1 . The issuer gateway verifies the split request according to its business and risk management policies, and responds 
with a new authorization loken in a message on path 402. The merchant lorwards the new authorization token in the 
capture message on path 242 to the acquirer gateway. This message is the same message as in the basic protocol 

so design. The merchant resubmits the authorization token in a second message on path 242, whenever the merchant 
has shipped the second part ol the shipment. If the merchant needs to lurther split the shipment, then messages on 
pains 402 and 242 can be repealed as needed. 

[0065] The 4-party protocol can support recurring and instalment features by a combination of additional information 
in th« authorization token, and messages on paths 402 and 242 of Figure 4. Specifically. Ihe steps of the basic protocol 
55 are modified as follows: 

I . The wallet initiation message contains additional parameters that identily the terms of any recurring or instalment 
payment agreed between the merchant and consumer. 
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2. The wallet should display these terms to ensure consumer awareness and agreement. The wallet forwards the 
additional parameters to the issuer gateway 

3. The issuer gateway verifies that the recurring or instalment terms are acceptable according to the issuer's busi- 
s ness and risk management policies. The issuer gateway includes the terms as additional parameters in the au- 
thorization token. 

4. The consumer's wallet forwards the authorization token (with additional parameters) to the merchant as in the 
basic protocol, in the message on path 228 of Figure 2A. 

10 

5. The capture of the first instalment or recurring payment occurs as with the basic protocol in the message on 
path 242 of Figure 2A. 

6. The merchant authorizes the second and subsequent instalment or recurring payments by sending the message 
on path 402 of Figure 4 to the issuer gateway The additional parameters in the authorization token allow the issuer 
gateway to recognize and appropriately handle these special payment types. The issuer gateway returns a new 
authorization token in another message on path 402 of Figure 4 that can be used both for captures (in a message 
on path 242 of Figure 4) and further authorizations by repeating messages on path 402 of Figure 4 as required. 

20 Japanese Payment Options (JPO) ~ 

[0066] SET supports a special business arrangement that is common in Japan. Issuing banks and merchants attract 
customers and business by offering instalment and other payment arrangements that are managed by the banks rather 
than the merchants. Thi3 involves a very complex protocol among all the SET participants. 

25 [0067] The 4-party protocol facilitates this feature because the consumer wallet and issuer gateway directly interact. 
Specifically, at step 2 of the protocol on path 224 of Figure 2A, the issuer could offer special payment arrangements 
to the consumer. These arrangements could be conditioned on the merchant name ( from he merchant's digital certif- 
icate), the amount of payment (from the initiation message), or other data supplied by the merchant in the initiation 
messaga. The remaining steps of the 4-party protocol can operate unchanged from the base design. This considerably 

30 simplifies the JPO protocol support (compared to SET), while providing an opportunity for issuers to differentiate them- 
selves and attract consumer business. 

Protocol Flow Variation 

3S [0068] Many variations of this 4-party design are possible. A principle one is shown in Figure 4. This variation has 
I he same four steps as the basic design, but the authorization token is sent directly from the issuer gateway to the 
merchant. Specifically: 

1. In Figure 4, path 220, the consumer uses a browser to shop at a merchant WWW site. The consumer presses 
<o a 'pay' button on the merchants HTML page, or otherwise indicates they are ready to make a payment. In Figure 

4, path 222, the Merchant sends a wallet initiation messaga to the consumer, containing payment amount, order 
description, timestamp, a random nonce, and possible additional data depending upon requirements. The mer- 
chant signs this initiation message and "includes a digital certificate provided by the acquiring bank. 

4s 2. In Figure 4, path 224, the Wallet initiation message causes the consumer's browser to start the consumers 
wallet The consumer is prompted to logon lo the wallet using use rid/password, smartcard, or other appropriate 
authentication mechanism. Wallet sends data from step 1 , plus the consumer's identity and authentication data to 
the issuer gateway. 

so 3. in Figure 4, path 402, the Issuer gateway verifies the merchant's signature and digital certificate to validate that 

the merchant and issuer share a common financial arrangement established by national law or a financial asso- 
ciation such as MasterCard, Visa, an ATM network, or similar organization. The issuer gateway authorizes payment 
via the issuer's credit card processing system. The issuer gateway generates and sends a signed authorization 
token directly to the merchant, along with the issuer gateway's certificate. The authorization token contains the 

Bs datafrom step 1 plus a merchant identifier and a reference lo the consumer's credit card number, as with the base 

protocol. 

Note that the authorization token is "bound" to the particular payment by the reference lo the consumer's credit 
card- number, merchant identifier, payment amount, timestamp, and nonce. This means that a specific authorization 
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token is good for just one payment. 

A. In Figure 4. path 402, the merchant verities both the issuer gateway's signature and the data in the authorization 
token. No separate realt'ine authorization is req«>ired since the payment is 'pre-authorized'' beiore it reaches the 
5 merchant. Merchant sends acknowledgment back to the issuer gateway. 

£. in Figure 4. path 224, the Issuer gateway sends acknowledge back to the consumer wallet, which terminates 
so that normal browsing can proceed. 

io e. In Figure 4. path 242, al some later time, the merchant submits the authorization token in a capture request lo 

tie acquirer's payment gateway. Thecaplure request lens the acquirer to actually post the charge lothe consumer's 
credit or debit account. 

[0069] The difference between this and the base design is that the issuer gateway sends the authorization token 

15 directly to the merchant, instead of relaying it through the consumer wallet, the primary advantage of this design is that 
it matches a thin* wallet design by moving responsibility lor error recovery to the issuer gateway The disadvantage 
is that the consumer wallet (and hence the consumer) has less opportunity to be aware of the progress ot the payment. 
[0070] To recap, the method described herein applies toboth norHnteractlve internet communications such as email, 
as well as to interactive applications such as the World Wide Web. and according to the preferred embodiment includes 

20 the step ot sending Irom a consumer's computer to an Issuer gateway tor an issHing bank, an authorization request 
message containing consumer identity and authentication information, payment amount, an order description, a times- 
tamp, a digital certificate representing a merchant, and a digital certificate representing the merchant's acquiring bank. 
The merchant's digital certificate contains a merchant identifier unique for the acquiring bank, and the acquiring bank's 
digital certificate contains a bank identifier unique among an banks sharing a common financial arrangement This is 

2S followed by the step of validating at the issuer gateway the merchant's certificate and the acquirer's certificate to prove 
that The merchant, acquirer, and issuer share a common financial arrangement, and then the issuer gateway verifies 
the consumer's account and ensures that funds and/or credit are available to support the payment amount, before 
authorizing payment by sending over the internet network an authorization token, an issuer's digital certificate, and a 
reference to the consumer's credit or debit card number. The authorization token includes the payment amount, order 

30 description, timestamp, a random nonce, the merchant identifier from the merchant's digital certificate, and the acquiring 
banK. identifier from the acquiring bank's digital certificate, plus a reference lothe consumer's credit or debit card number 
and is digitally signed by the issuing bank. The merchant's computer receives the authorization token and fulfils the 
order description. 

[0071] The method may optionally include sending from a merchant's computer over an internet network to a con- 

35 sumer's computer, a merchant message including a wallet initiation message, a merchant digital certificate, and a 
digital certificatefrom an acquiring bank, the wallet initiation message including a payment amount, an order description, 
and a timestamp. A consumer's wallet program m the consumer's computer is started in response to the wallet initiation 
message, and then the consumer's wallet program sends the authorization request message. 
[0072] The wallet initiation message may include a merchant's digital signature m the authorization request message, 

40 wilh the issuer gateway verifying the merchant's signature to prove that the consumer is dealing with the actual mer- 
chant. ... • 
[0073] The merchant's computer can perform the steps of receiving the authorization token, verifying the issuer's 
signature, digital certificate, the payment amount and merchant identity in the authorization token, verifying the fresh- 
ness of the authorization token via the timestamp in the token, using the nonce in the authorization token to recognize 

45 duplicate tokens, and fulfilling the order description. 

[0074] The merchant is able to ctaim payment through the acquiring bank by forwarding the customer reference 
number and payment amount to the acquiring bank. In the case of a subsequent depute, the merchant proves payment 
authorization by submitting a copy ol the authorization token and issuer's digital certificate lo the acquiring bank. The 
acquiring bank verifies the issuers signature on Ihe authorization token, validates the issuer's digital certificate, checks 

so for ouplicates via the timestamp in the authorization token, and then the acquiring bank pays the amount indicated in 
the authorization token. 

[0075] The authorization request message and author izalkxi token can include a hash of an order description instead 
of the actual order description, the order description itself being available separately at the merchant, the merchant 
validating that the authorization token refers to the same order description by comparing the hash of the order descnp- 
55 tion in the authorization token against a (ocatly-computed hash of the same order description. 
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Claims 

1. A method lor performing electronic transactions over a computer network, comprising; 

5 sending from a merchant's computer (204) over an internet network to a consumer's computer (202), a mer- 

chant message including a wallet initiation message (222), a merchant digital signature, and a digital certificate 
from an acquiring bank (208), said wallet initiation message including a payment amount, an order description, 
and a timestamp; (step 304) 

starling a consumer's wallet program in said consumer's computer in response to said wallet initiation mes- 
sage; 

sending from said consumer's computer consumer identity and authentication information and said merchant 
message, to an issuer gateway (214) for an issuing bank (212); 

verifying at said issuer gateway said merchant's signature to prove that the consumer is dealing with the actual 
merchant and validating at said issuer gateway the merchant's certificate and the acquirer's certfficale to prove 

is that the merchant and issuer share a common financial arrangement; 

said issuer gateway verifying the consumers account and ensuring thai funds and/or credit are available to 
support the payment amount (step 308), then authorizing payment by sending over said internet network an 
authorization token (254), an Issuer's digital certificate, said wallet initiation message, and a reference (252") 
to said consumer's credit (250) or debit card number, (step 310) 

zo said authorization token including the payment amount, order descriptionrHmestamp, a random nonce plus a 

merchant identifier and a reference to the consumer's credit or debit card number; and 
said merchant's computer receiving said authorization token and fulfilling said order description. 

2. The method of claim 1, which further comprises: 

2$ sending from said consumer's computer a start message (200) over the internet network to the merchant's 

computer, to initiate said merchant's message. 

3. The method ot claim 1 or 2, wherein said wallet initiation message includes a nonce. 

30 4. The method of claim 1 . 2 or 3. wherein said merchant's computer further performs the steps comprising: 
receiving said authorization token; 

verifying the issuer's signature, digital certificate, the payment amount and merchant identity in the authoriza- 
tion token; 

35 verifying the freshness of the authorization token via the timestamp in the token; 

using the nonce in the authorization token to recognize duplicate tokens; and 
fulfilling said order description. 

5, The method of any of claims 1 to 4. wherein said consumer identity and authentication information is a userid and 
40 a password. 

6. The method of any preceding claim, wherein said issuer gateway sends said authorization token to said consumer, 
and the consumer forwards said authorization token to said merchant. 

45 7. The method ol any ol claims 1 to 5, wherein said issuer gateway sends said authorization token directly to said 
merchant. 

8. The method of any preceding claim, wherein said reference to said credit card is a consumer credit or a debit 
account number. 

50 

9. The method ot any of claims 1 to 7, wherein said reference to said credit card fs an alias card number that is 
mapoed at the issuing bank to the real card number, thereby preventing use ol the consumer's credit card number 
without said authorization token. 

ss 10. The method of any ot claims t to 7, wherein said relerence to said card is an authorization number allocated 
uniquely by the issuer gateway for each authorization, enabling it to be passed by an acquirer gateway back to 
the issuing bank in a capture message (256) ; 

said issuing bank maintaining a dalabase mapping authorization numbers to card numbers, so that when 
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Ihe .ssuing bank receives Ihe capture message, it uses the database mapping to determine the consumer's card 
number. 

11, "me method of any preceding claim, wherein said authorization token includes a dummy card number lor use in 
routing payment to an appropriate one ol a plurality ol issuing banks (212A - 212C); 

sakJ dummy card number being shared among all cardholders of a pfrrtlcular issuing bank. 

12. Tne method of any preceding claim, wherein split shipments are supported by an additional message Interaction 
between the merchant and Issuer gateway, comprising: 

the merchant sending the authorization token to the issuer gateway identified in the issuer's digital certificate, 
including details ol a split requirement, such as the amount of a first payment, the merchant authenticating 
the request by sipping it and including the merchant's digital certificate; 

the issuer gateway verifying that the merchant signing message is the same merchant that signed an onginal 
request, verifying the split request according to business and risk management policies, and responding with 
a new authorization token in a message to the merchant; 

the merchant torwarding the new authorization token in a capture message the acquirer gateway; 
the merchant resubmitting the new authorization token to the acquirer gateway in a second message, when- 
ever Ihe merchant has shipped a second part of the shipment. _ 

1 3 The method ol any preceding claims, wherein Japanese Payment Options are provided, comprising; 

ihe issuer ottering special payment arrangements to the consumer, conditioned on the merchant name from 
the merchant's digital certificate and me amount of payment Irom the initiation message. 

25 14. Tho method ol any preceding claim, wherein said acquiring bank's digital certificate contains a network address 
or URL that identifies the network location ol said acquiring bank contacted via an internet network as part of a 
payment protocol. 

15. Tne method of any preceding claim, wherein said issuer's digital certificate contains a network address or URL 
30 that identilies the network location of the issuer contacted via an internet network as part of a payment protocol. 

16. A system tor performing electronic transactions over a computer network, comprising: 

a merchant's computer (204) for sending over an internet network to a consumer's computer (202), a merchant 
*5 message including a wallet initiation message (222), a merchant digital signature, and a digital certificate from 

an acquiring bank (208), said waltel initiation message including a payment amount, an order descnplion, and 

a cc^Ss wallet program in said consumer's computer responsive to said wallet initiation message, lor 
sending from said consumer's computer consumer identity and authentication information and said merchant 
40 message, to an issuer gateway (21 4) for an issuing bank (21 2); 

an issuer gateway (or verifying said merchant's signature to prove that the consumer is dealing wtth the actual 
merchant and validating at said issuer gateway the merchant's certificate and the acquirer's certificate to prove 
that the merchant and issuer share a common financial arrangement; 

said issuer gateway verifying the consumers account and ensuring that funds and/or credit are available to 
45 support the payment amount, then authorizing payment by sending over said internet networkan authorization 

token (254), an issuer's digital certificate, said wallet initiation message, and a reference (252 i ) to said con* 
sumers credit (250) or debit card number, 

said authorization token including the payment amount, order description, limeslamp, a random nonce plus a 
merchant identifier and a reference to the consumers credit or debit card number; and 
so said merchant's computer receiving said authorization token and fulfilling said order description. 

17. A computer program product, comprising: 

computer program code means for sending from a merchant's computer (204) over an internet network to a 
ss consumer's computer (202), a merchant message including a wallel initiation message (222), a merchant 

digital signature, and a digital certificate from an acquiring bank (208), said wallet initiation message including 
a payment amount, an order description, and a timestamp; 

computer program code means lor starting a consumer's wallet program in said consumer's computer m re- 
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soonse to said wallel initiation message; 

computer program code means lor sending from said consumer's computer consumer identity and authenti- 
cation information and said merchant message, to an issuer gateway (21 4) for an issuing bank (21 2); 
computer program code means for verifying at said issuer gateway said merchant's signature to prove that 
s the consumer is dealing with the actual merchant and validating at said Issuer gateway the merchant's certif- 

icate and the acquirer's certificate to prove that the merchant and issuer share a common financial arrange- 
menti 

said issuer gateway verifying the consumer's account and ensuring that funds andtor credit are available to 
support the payment amount, then authorizing payment by sending over said internet network an authorization 
io token (254), an Issuer's digital certificate, said wallet initiation message, and a reference (252 1 ) to said con- 

sumer's credit (250) or debit card number; 

said authorization token including the paymenl amount, ofder description, timsstamp. a random nonce plusa 
merchant identifier and a reference to the consumer's credit or debit card number; and 
said merchant's computer receiving said authorization token and fulfilling said order description. 
is . 
18. A method for psfforming electronic transactions over a computer network, comprising: 

sending from a consumers computer (202) to an Issuer gateway (21 4) for an issuing bank (21 2). an authori- 
zation request message containing consumer identity and authentication information, payment amount, an 
order description, a tinestamp, a digital certificate representing a merchant and a digital certificate represent- 
ing the merchant's acquiring bank; , . 

said merchant digital certificate containing a merchant identifier unique lor the acquiring bank (20B). 
said acquiring bank's digital certificate containing a bank identifier unique among all banks sharing a common 
'inancial arrangement; . 
validating at said issue, gateway the merchant's certificate and the acquirer's certificate to prove that the 
merchant, acquirer, and issuer share a common financial arrangement; 

said issuergateway verifying the consumer's account and ensuring that funds and/or credit are availabte to 
support the payment amount, then authorizing payment by sending over s**"*™?™^™*"*"™™ 
token(254), an issuer's digital certificate, and a reference (252') to sari consumer's credit (250) or debit card 

said Authorization token including the payment amount, order description, timestamp, a ^^nonce. said 
nwchantrientifierlromthemercham's^ 

bank's digital certificate, plus a reference to the consumer's credit or debit card number, 
said authorization token being digitally signed by the issuing bank; and 
35 said merchant's computer receiving said authorization token and fulfilling said order description. 



20 



25 



19. The method of claim 18. whk* further comprises: sending from a merchant's computer over ar, ^teme netwo* 
to a consumer's computer, a merchant message including a wallet initials message, a merchant d.g.tal cerM"*!* 
and a digital certificate from an acquiring bank, said wallet initiation message including a payment amount, an 
40 orcter description, and a timestamp; 

starting a consumer's wallet program in said consumer's computer in response to said wallet initiation mes- 
sage* 

said consumers wallet program sending the authorization request message. 



45 
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20. The method ol claim 19, which further comprises; 



including with the wallel initiation message a merchant's digital signature or the walleliniliation me««W 
including the wallet initiation message and said merchant's digital signature in the authorization request mes- 



Sn^ing at said issuer gateway said merchant's signature to prove that the consumer is dealing with the actual 
merchant. 

21. The method ol any of claims 18 to 20, wherein the merchant claims payment through the acquiring bank by for- 
55 warding the customer reference number and payment amount to the acquiring bank. 

22 The method ol any of claims 18 lo 21 . wherein the merchant claims payment Ihrough the acquiring bank by lor- 
warding ihe authorization token and issuer's digital certificate to the acquiring bank; 
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the acquiring bank verifying the issuer's signature on the authorization token, validating the issuer's digital 
certificate, checking for duplicates via the timestamp in the authorization token; and the acquiring bank paying the 
amount indicated in the authorization token. 

23. The method of any of claims 1 8 to 22, wherein said authorization request message and authorization token includes 
a hash of an order description hslead of the actual order description, the .order description itself being available 
separately at the merchant, the merchant validating that the authorization token refers to the same orderdescrption 
by comparing the hash ol the order description in the authorization token against a locally-computed hash of the 
same order description. 

24. The method of any of claims 1 8 to 23, wherein the confidentiality of said credit or debit account number is maintained 
by using a higher-level security protocol, such as encrypted email or SSL to protect the communications among 
the consumer and the issuer gateway, the consumer and the merchant, the issuer gateway and the merchant, 
and, if applicable, the merchant and the acquirer. 
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